Instant messaging (IM) services provide end users means for fast, interactive, mainly text-based communication. A user of an IM service may talk to one or more other users, regardless of where they might be, at the same time. With the addition of a service that keeps track of online status and availability of partners or “friends” of a user, the functionality of the IM service is greatly enhanced. This service is called a presence service. The combination of instant messaging and presence services is called Instant Messaging and Presence Service (IMPS). One instance of IMPS is Open Mobile Alliance Instant Messaging and Presence Service (OMA IMPS). Open Mobile Alliance (OMA) defines a set of universal specifications for mobile IMPS, as well as procedures and tools for testing conformance and interoperability. The specifications are for exchanging messages and presence information between mobile devices, mobile services, and Internet-based instant messaging services.
FIG. 1 illustrates a basic mobile IMPS system. A number of mobile devices, such as a mobile phone 10 and a laptop computer 20, can be connected via a mobile network 50 and possibly one or more intermediary network 60 to an IMPS server 40. Typically, the Internet is used as the intermediary network. Also, non-mobile devices, such as a desktop personal computer (PC) 30, may be served by the IMPS system through the network connections as well.
Presence information of a user is organized in the form of presence attributes. A description of prior art presence attributes can be found in U.S. Patent Application Publication No. 2003/0065788, which discloses that the presence attributes are divided into several classes, and each class comprises one or more presence attributes:                Client Status: attributes describing the availability of the client for communication,        User Status: attributes describing the availability of the user for communication,        Local Information: attributes describing local environment of the user,        Personal Status: attributes describing user's personal status,        Client Capabilities: attributes describing the capabilities of the client to support different means of communication, different media types and different features,        User Attributes: attributes allowing the client device or the user to define their own textual presence values and references to external values, and        Extended Presence Information: vendor specific or service provider dynamically defined non-standard presence attributes.        
Since presence information is personal, it is only made available according to a user's wishes. A user can create a contact list of other users (e.g. friends or partners), and block or grant accesses to own presence information from specific users. Contact list and block/grant list are not part of the presence information. The lists are stored on the server.
A presence attribute according to this prior art reference generally comprises an identifier part (Attribute Name) and a plurality of value fields (Qualifier, Authority and Value), as shown in FIG. 2.
A user device of an IMPS system includes one or more IMPS clients. A client is an implementation of the IMPS service that allows a user to access the service. The client may be hardware, software, firmware, or any combination thereof. The client is conceptually device-independent, so that a connection to an IMPS server is considered to be between a client and the server. Conventionally, a connection to the IMPS server is identified by two identities: (1) user identity (ID), comprising an user name and a possible password for authentication, and (2) client ID, comprising a client name and a client address, for identifying the particular client that is used to access the IMPS system (U.S. Patent Application Publication No. 2003/0028597, FIG. 2B). When a user accesses the IMPS system, the client needs to provide both user ID and client ID. A user device may have a plurality of users using the same client. By separating user identity and client identity, a user can get instant messages from different clients and different users using the same client can get their own instant messages.
Today's user devices are increasingly personal. One user typically uses one or more user devices, such as a mobile phone and a PDA (personal data assistant), at a time. Instances of one user device being used by two or more users at the same time may still exist, especially in non-mobile devices, but such instances are increasingly rare. An advanced user device may contain one or more clients that interact with the IMPS server for obtaining the services. From the standpoint of OMA, a user device may have one or more IMPS clients (i.e. OMA IMPS) and one or more third-party (non-OMA) application clients (3APP clients). A client may further include one or more applications such as instant messaging and interactive games.
The OMA IMPS solution allows a client to log on to a server and perform various transactions. A connection between a client and a server is called a session. Since one user may want to use more than one client at same time, it is desired that a server is capable of handling multiple sessions of the same user at same time. In order to do so, however, it is necessary to distinguish one session from another.
Existing protocols (e.g. OMA IMPS version 1.1 and 1.2) do not specifically address the issue of handling instant messages and other information that resides in the server when there is another client of the same user trying to log in. Most of the servers disconnect the previous client in order to guarantee that there is only one client of a user logged in any one time.
In order to provide the user with a smooth operation of multiple sessions, a proposed new specification, OMA IMPS Version 1.3, mandates several requirements for the server and the client. It is believed that if these requirements are fulfilled, the concurrent sessions of a user will not interfere with each other. Moreover, presence information subscriptions will be separated for each session, and joined groups will be separated for each session.
Table 1 is a list of general requirements for use of multiple applications or sessions.
TABLE 1General Requirements for use of multiple applications/sessionsRefRequirementsGEN-11Devices, Clients and 3APPs MAY be able to establish anynumber of separate sessions on any Server.GEN-12Devices, Clients and 3APPs using separate sessions SHALLuse different identification.GEN-13Server SHALL NOT accept creatingseparate sessions from ClientIDs that are already in usein other sessions on a per user basis.GEN-14Server SHALL accept creation ofseparate sessions from a unique ClientID that is not in usein any other session on a per user basis.GEN-15Server SHALL NOT disconnect previous session(s) when a newsession is established on a per user basis.GEN-16Server MAY limit the number of concurrent sessions and denyestablishing new sessions for this reason.
(Source: OMA IMPS Delta Requirements, Candidate version 1.3, 18 Nov. 2004, Open Mobile Alliance OMA-RD_IMPSDelta-V1—3-20041118-C.)
What is needed is a method enabling multiple sessions and applications in instant messaging and presence service, fulfilling the general requirements of Table 1.